InfoMagic Internet Tools 1995 April/Internet Tools.iso/dos_win/winsock/wsock20/minutes.txt

Text File | 1994-12-16 | 45.3 KB | 1,676 lines

Meeting Minutes, Dec 12 Windows Sockets 2.0 Meeting

Following are the minutes from the December 12, 1994 meeting
of the Windows Sockets 2.0 Generic API Extensions and
Operating Framework functionality groups.  These notes are
in fairly raw form, but they should contain all the
important questions and issues raised.  Generally the
company name of a speaker is used, but in some cases, an
individual's first name is used to identify the speaker.
Here is a list of the full names of speakers:

davea: Dave Anderson of Intel
charlie: Charlie Tai of Intel
henry: Henry Sanders of Microsoft
keith: Keith More of Microsoft
martin: Martin Hall of JSB
mark: Mark Towfiq of SunSoft
davidtr: David Treadwell of Microsoft
alden: Algen Gannon of Microsoft

In some cases the speaker name was lost, either because of
the speed of the conversation or because they did not state
their name/company.  In these cases the speaker is
identified as "?".  Breaks between Q&A sessions (with
presenters talking) are identified by "***".

The unresolved issues that came up at the meeting are as
follows:

* what to do about differences between error returns between
error codes, eg -1 as int in 16bit and 32bit?

*  what will happen with the winsock2 DLL source code?  will
it be made available?  people are concerned about the
dependency created by the architecture.

* what sort of debugging support will the winsock2 DLL have?

* what is meant by "interrupt context"?  spec needs to
identify this very exactly for win 3.1.

* will there be some mechanism for "priming" interrupts to
guarantee mutual exclusion of send and receive calls?

* various issues were raised with regard to the proposed
structure for QOS information.

* how does QOS relate to RSVP? simple ethernet?

* is there a need for a generic, asynchrouous (overlapped)
ioctl/setsockopt function?

* in the face of multiple, shared sockets, how does
WSAAsyncSelect() work?  three proposals:
     - totally independent notification on each handle
     - notification is independent for each event
     - only one WSAAsyncSelect outstanding for each handle
(like winsock 1.1)

* if an app asks for connect data but the protocol does not
support it, does the request fail or does the connect data
get ignored?  (general concensus was to fail)

* is the output flags param of WSARecv used to indicate
MSG_OOB as well as MSG_PARTIAL?

* should winsock2 define a generic configuration mechanism?

* what will be the process for resolving open issues?

* will there be any semantic differences between winsock 1.1
and 2.0? (general concensus: NO)

* will there be a new DLL name for winsock2?  or will
"winsock.dll" and "wsock32.dll" export the 2.0 semantics?
(general concensus: no new DLL name)

* how does someone choose between multiple instances of the
same type of provider?  for example, two tcpips, one for lan
and one for dialup.  is there a control panel applet or
somesuch that controls this?

* how will scatter/gather semantics be supported?


Start of meeting minutes:

novell: is there interest in Windows Sockets on other
platforms?

davea: a little.  who wants to step up and do the work?
intel is mainly interested in Windows.

?: the macintosh?

davea: same answer.  intel won't be spending a lot of time
on that, but that doesn't stop someone else from doing it.

***

novell: are servers at well-known port addresses?

davea: that is part of the name resolution group solution,
but it is possible to have dynamic server addresses with
their work.

wrq: is someone comes out with a new protocol, does a server
need to know about the protocol?  why?

davea: servers know the attributes that they require, they
search for protocols that have those attributes, and
bind/listen on those protocols.  so they do not need to know
about future protocols.

novell: can servers bind to dynamic or static addresses?

davea: the goal of the name resolution group is to define a
programmatic interface to existing and future name services
that encompases the usual types opf features exported by
name services.  gives example of DNS needing static ports,
bindery/SAP needing dynamic.

novell: why not do multiple listens over multiple protocols
on one socket?

henry: this would make implementation of multiple providers
very difficult.

davea: interesting idea, but it is solved in other ways.

***

wrq: what did you do about differences between error returns
between error codes, eg -1 as int in 16bit and 32bit

keith: spi doesn't do GetLastError(), passes out params

wrq: 16bit returns 64k, 32bit returns 4gig

henry: that is really an api issue

novell: whether handle is real handle is job of svc
provider?

keith: yes, if implemented as real file system, file handles
drop out.  if not file system, upcalls generate socket
handles uniquely.

ibm: routing function in ws2 dll: app says "I want that
stack"  are there circumstances where ws2 dll makes
decision?

keith: no, ws2 dll gives you info and app makes decision

ibm:

davea: triple doesn't necessarily define a provider;
provider ID enables unique determination.  use WSASocket in
conjunction with info from PROTOCOL_INFO

ibm: example where providers support multiple transport
protocols, media

davea: application has to make the choices, or else ws2
picks the first one that works

keith: endpoint is traditionally a triple, but it is really
a quad including provider id

novell: triple might be supported by multiple providers on
the same machine

henry: might have one ethernet tcpip, one slip, this enables
that situation to work

novell: isn't it weird to use triple to distinguish those
characteristics? don't they uniquely determine stack?

henry: not necessarily unique

davea: in telephony, there may be multiple stacks which
speak the same protocol.  need another tag to identify.

wrq: like to see included doc on how inferred priority is
implemented

ftp: why there are differences on why there are differences
between 16bit spi and 32bit spi

keith: need real file system handles on 32bit

ftp: how does app decide whether to use file system calls or
ws2 calls

davea: a bit in PROTOCOL_INFO about whether socket handles
are real

westwind: nt, sync vs. async socket handles on nt

ftp: same blocking mechanism in 16bit and 32bit spis?

keith: no, spis differ

novell: select() on different socket handles from different
providers?

keith: doesn't work, but other mechanisms provide same
functionality, davea will discuss later

***

distinct: a way to dynamically load, unload a svc provider?
eg over dialup

keith: those decisions up to ws2 dll, svc providers loaded
on demand as apps request them

wrq: unloaded on demand?

keith: I would imagine, no reason why couldn't

netmanage:  why not defer blocking to provider on both 16bit
and 32bit

davea: blocking differs between providers, effects apps,
doing it once in ws2 dll makes it consistent across
providers

netmanage: multiple ws2 dlls?

davea: one ws2 dll.  comes with os instead of coming with
every provider.

netmanage:  who writes it?

davea: now stack vendors write entire winsock dll.
proposing that os vendor (microsoft) on 32bit write and
freely distribute ws2 dll.  svc providers simply write to
spi.  16bit, is demand, intel would make freely available,
based on work already done.  no proliferation os ws2 dlls so
behavior is standardized, stack vendors don't need to
duplicate effort.

ibm: have ms and intel agreed to do this?

davea: yes, microsoft and intel have agreed to do it.

novell: demands 16bit ws2 dll

ftp: who assigns provider Ids

davea: jsb willing to provide a clearinghouse of Ids.
ensures it isn't a duplicate of something already defined.

novell: clashes with rfcs?

davea: well known ports don't go only to ws2 clearinghouse.
iana (or whoever) does that assignment.

sunsoft: addr family make up in winsock.

sunsoft: why doesn't microsoft supply both 16bit and 32bit?

microsoft: we want to focus our efforts on the 32-bit SPI,
plus Intel has done some work with PII that can be leveraged
as a starting point for the 16-bit DLL.

novell: we need a 16-bit interface today

davea: intel agress to provide it asap

?: who agrees to fix it?  update it?

davea: intel isn't that business, but jsb is in that
business.  jsb is willing to work on building it and
providing technical services to support.

ftp: middle `95, ws2 dll and source code and build
environment freely available on anon ftp?

davea: hesitant on exact timeframe, 2nd half, depending on
ws2 progress, you will have everything you need

ftp: providers won't want to depend on other companies to
fix problems; want source code

henry: need one common dll, source code results in multiple
ws2 dlls

ftp: don't want to have multiple dependencies

?: give out source code on nda?

dintinct: defined way to provide updates to providers?

novell: fix quickness depends on price paid?

ftp: winsock2 dll given out by ftp etc?

davea: near term will ship with operating system

ftp: not for 16bit

davea: valid concerns, need to find a solution that doesn't
result in proliferation of ws2 dlls.  open to suggestions.
hampered by fact that ws2 community is not real legal
entity.

ftp: proposes making source code available

distinct: difficult because which ws2 dll works, gets
installed

novell: but providers need to give fixes to customers

henry: can make recent versions of dll available via anon
ftp

?: when provider makes a change, they must give it back to
clearinghouse

ftp: wants to hear suggestions, schedule says shipping `95.
need to resolve problems asap.

davea: interested in hearing solutions

walldata: this puts svc providers in same position as app
providers when you don't have compete control--it works over
some ws dlls, not over others.  cooperation is required,
someone at ws2 level is required to want to fix it.  it can
work, but it requires effort.

jsb: ws2 dlls are as thin as possible to minimize problems.
procedents exist on this:  tapi, odbc, video for windows.

distinct: is svc providers have different Ids, what about
validation process?

davea: wsat will be enhanced

walldata:  have a bakeoff!

jsb: three staging posts between now and ws2 spec
finalization:
     Q1 95 have consolidated drafts of complete ws2 spec
     SDKs need to be made available
     learn from mistakes in ws 1.1, have bakeoffs to
validate spec and implementations

these staging posts are key and occur before ws2 is "done"

netmanage: if a problem, have to locate where the problem.
source code would help.

walldata: yes, debugging paradigm would help

netmanage: app makes blocking call, ws dll issues
nonblocking call to provider?

davea: yes in 16bit, but in 32bit provider handles all
blocking

sunsoft: problem with core assumption of this.  lots of
mementum in winsock.  concerned that departure from ws1.1
api, how does a svc provider handle the tons of apps that
exist?  thunking to ws2 dll?

davea:  good question.  couple of trains of thought.  one
notion is that ws2 dll is both a ws1.1 and ws2 dll.  another
is that 1.1 is as it, and ws2 is different.  not bottommed
out on that yet.  this is a clear issue that must be
resolved.  feels that we would be better served by keeping
dlls separate.

cisco: if dlls are separate, then what is motivation for
going to ws2?

davea: features, plus ws1.1 is limited to tcpip

sunsoft:  will discuss this issue further later

***

novell: have to worry about handling recv/send from sombody
else's callback?

davea: protocol_info struct indicates whether provider can
handle send/recv at interrupt context.

distinct:  so will ws2 dll work with interrupt context?

henry: clarification on what is "interrupt context"

davea: point is to provide time-sensitive applications a
mechanism to override windows messages

distinct:  all svc providers are dlls?

keith:  yes, if you have a kernel provider then you supply a
provider dll to interface to the kernel component

distinct: then any kernel components are kernel specific?

keith: yes

novell: difficult to shield yourself from live interrupt
callback considerations

wrq: can always fail send or recv

novell: need to nail down what is meant by interrupt
context, need to be specific on what is meant by each
context.  if I am going to say that I support it, I want to
know what it means.

***

netmanage: for tcpip, you must keep data for retransmissions

davea: we suggest that send buffering, even for overlapped
io the send gets bufferred by default.  but an app can turn
off send bufferring, which means that apc/event/callback is
called when data is ack'ed.

novell: when you make the final callback, doesn't that mean
that the data has been ack'ed?

henry: completion only means that data buffer is freed

ftp: send completion in nonbufferring means that remote
transport has it

alden: does this force application to stop-and-wait?

keith: no, you may put down multiple async send buffers

alden: this requires send windowing in app

henry: depends on app requirements

wrq: a way to prime send completion?  there are instances
where I want only to send out of interrupt context.  a
mechanism to initiate this?

henry: why do you need this?

wrq: possible to get completion before api call completing,
need notification of completion

henry: not necessarily true that interrupt context doesn't
mean that ack hasn't arrived

wrq: 8k buffer, 2k write chunks, when you get callback you
might never get back to app

henry: missing something, let's discuss later.  callback is
in "some" user context, not kernel

ftp: a cancellation mechanism?

keith: no, win32 lacks cancellation

ftp: then I cannot do a 64k send?  what if it takes too
long?

keith: just close socket

henry: indeterminate state--how much was sent?

?: session is in indeterminate state when that happens,
might as well close anyway.

***

novell: are apcs targeted at a specific thread or process?

keith: thread

novell: then you could not have just one thread handling
callbacks

keith: no, callbacks are thread specific

davea: overlapped i/o is NOT optional; every provider must
support it

***

novell: can ws2 address issue with 1.1 and fd_close?

keith: responsibility of spec clarification comittee

novell: needs to be nailed down by somebody

ftp (bob): current thinking of clarifications group is to
say that apps must do recv until they get 0 bytes read

davea: not addresses in these documents, but it does need to
be addressed

distinct:  2.0 a different spec?  does the issue exist in
2.0?

davea:  need for no ambiguity on this issue in 2.0, overlap
between generic api and clarifications groups

distinct:  right now, everyone does recv() when you get an
fd_close

***

5 minute break

***

cisco: when mapping qos name to qos, have different qos
specs for different types of data eg mpeg?

charlie: yes, exactly

***

?: if peak == average, what do you do with burst length?

charlie:  burst length indicates time of burst

?: but what about burst length?

charlie: it is irrelevant in that case

cisco: problem with specifying burst without a time
parameter.  this is a problem for the guy who implements the
service.

charlie:  max time for peak is limited by burst length.

cisco: fine for atm, but does not work for a standard
interface eg 56k line because you cannot exceed 56k.

at&t: maybe definitions of peak and average are at issue--
what do they mean?

charlie: average is over lifetime of connection

cisco: spoke on this at ietf, what you want is the token
bucket model, use two params instead of three. should use
unit of time and bits/bytes that you want to send in that
period of time.

at&t: how does continuous traffic work in that model?

charlie:  this is just a proposal, will need to discuss
further

novell: how to map for ethernet folks?

davea: protocol_info struct tells whether you support qos,
can assert that you cannot deal with it.  also, you can say
that you only support qos and only take "best effort"
requests.

cisco: goal to specify api for qos that can be supported
across wide variety of media, wide variety of networks,
including atm, ethernet, token ring etc.  current spec makes
it difficult to implement in ethernet/token ring w/o loss of
value.

ibm: disagrees about loss of value, can implement via
translation into token bucket.  maybe enable different
approaches to qos.

cisco: token bucket model provides same model for atm, so
atm does not lose but everything else gains?

ftp: relationship to rsvp proposal?

charlie:  good question.  we are tracking, some people here
can help us understand current status of rsvp to tell us how
to integrate with rsvp.  goal is a single api interface that
can support/accomodate all these.

cisco: talked to those people, looking at rsvp, they think
token bucket makes more sense.

charlie: let's postpone detailed discussion.

davea: as far as I understand, this model is not at variance
with rsvp.

henry: issues with using it at connect

cisco: yes, a flow can change its characteristics, rsvp
sender can change characteristics when a new sender comes
up: reservation changes.  must be able to support at other
then connect time.

ftp: a server has no concept of "connect time"

henry:  odd doing it at connect time; unify in one api?

davea: issue needs more discussion

***

?: when an app specifies flow, do you get that flow?

charlie:  app specifies, provider accepts/rejects

at&t: how can cost be a single int32?

davea: disagreement over that issue, it is outstanding

cisco: thinking about predictive service?

charlie: yes, we think about it.  best effort means more
than a hint; it checks feasibility of setting up a
connection.  20mb/sec over ethernet clearly will not work.

cisco: best effort != predictive service, don't call it that

charlie: yes

at&t: ???

charlie:???

***

cisco: what about iso tp?  thinking about that?

henry: no, straight to atm

cisco:  what about cell loss

charlie: eg video audio don't care about lost packets

cisco: want to detect this

many: don't care about that

cisco: but you could lose a cell in a packet

ibm: many don't care about that

cisco: many app vendors don't want retransmission, but they
may readjust sending parameters.  so they need a cell loss
detection mechanism.

henry: we could easily solve detection of packet/cell loss

***

distinct: how does an app get a qos group id?

charlie: first connection gets group id.  following conns
pass in same group id.

distinct:  not clear on how group priorities works

charlie: data on high priority sockets send first

distinct:  how to resolve between groups?

charlie:  equal footing between different groups

distinct:  need to resolve contention across groups

ibm: next step: os scheduling issues

davea: process priority etc is an os issue, we wanted to
draw a line.  you can reap useful benefits with this.

distinct: priority done by ws2 or provider?

davea: provider.

distinct: raising this because it will cause problems across
providers and groups.

intel: svc provider deals with it, socket groups cannot span
providers.

davea: os capability issues.  win3.1 does not handle this;
win32 does.

distinct: thread priorities across priorities?

davea: yes, it is an os issue

att: group qos encompases several sockets

charlie:  yes

ibm: confused about what are groups?  same as programs?

intel: establishes priotiry within a group

ibm: mpeg defines a program, this sounds like a similiar
concept

davea:  many xports under ws2 are connection oritnted.  must
establish conn first, then multiplex several sockets.  svc
provider needs a clue for params of 1st underlying conn.  in
most situations, cannot go after the fact and establish
different qos.

at&t: requirement that everything goes in the same group?

davea: priority can be a local matter on a host or bilateral
across the conn.  constrained group enables the latter but
does not mandate it.

cisco:  if going over wider network (mbone), you tell router
that you want to join multicast feed and receive with best
effort.  you also get qos params of sender.  user looks at
quality, can request more bandwidth.  you don't want to tie
it down, you might want to change it later.  need a
renegotiation capability.

sunsoft:  just an ioctl?

davea: renegotiating qos is an async function, current ioctl
setting apis are stateless, synchronous

henry: there is a mechanism proposed for qos change
notification.  can leverage this to attempt to solve
renegotiation problem.

wrq: socket priority goes over only a single provider, yes?
one app can't deal with multiple providers grouped in a
socket group?

davea:  yes

***

break for lunch

***

distinct: when sharing sockets across tasks, how does event
notification work?

davea: two proposals: one is event notification is
independent per handle.  example of how that might work.  if
you want two processes to get notifications, they both get
them, but who knows how the app is supposed to handle that;
it is their problem.  other solution: for any particular
network event, only one process registers for the event.
last one to register gets it.  this is listed as an open
issue--feedback?

netmanage: when you dupe, do you get the same socket or
another socket?

davea: you get another handle into the socket.  underlying
stuff is the same.  it may be a different handle value.

netmanage: can't I just use the same socket handle value?

davea: socket handles are specific to the process in which
they are allocated.  might get away with this in win16, but
in win32 where socket descriptors are per-process this
doesn't work.

netmanage: who handles duplication? ws2 or provider?

davea: keith, do they differ?

keith: in 32bit if handles are real file system handles,
system handles it.  in 16bit and 32bit with fake socket
handles, ws2 dll does the duplication.

davea: in 16bit, ws2 dll handles all of it; generates a new
descriptor, etc.  example of how this works.

netmanage: provider doesn't even know that there are
multiple handles for a particular socket?

davea: subject to constraint of handling of notification,
maybe.  issue outstanding.

digital: have you worked out a way that this socket is
shutdown?

davea: refcnts, last one out turns out the lights.

digital: when a spawned daemongoes, last one kills it?

davea: yes

ftp: more questions on how to do notification?

henry & davea: outstanding issue; two schools of thought.
describes two schools of thought again.

henry: in ws1.1, handle duplication was "optional" as an
extension.  how did people do it?

distinct: ws1.1 dll shares memory.

henry: how to handle notifications?

distinct: notification is dependent (only one; last one gets
it).  proposes making it independent

henry:  issue with reenabling--how do you know how to rearm?

ftp: can it be done in a way to just pass handle to a child
task?  parent cannot continue to access socket?

davea: app can do this, but how do you know that handle
value isn't already allocated in the child task?

sunsoft: the proposal is different, they want to have one
process per socket at a time.

davea & others: requirement is SHARING, not socket PASSING.
many apps need actual sharing.

at&t: do both handles get notification?

davea: that is the issue, whether it goes to both handles or
one handle

wrq: back to shutdown issue: what about the shutdown() call?

davea: shutdown() does an actual shutdown().

wrq: is there a notification mechanism?

distinct & davea: that is up to the application to handle.
shared sockets create lots of problems.

ftp: then why do them?

davea: lots of neat wins, e.g. if sending and receiving ends
of sockets are separate processes, sharing sockets enables
it.

...many other suggestions...

ftp: the more stuff like this we create, the more support
work is created

distinct: servers want this to work

henry: on mailing list, people do want SHARED sockets

davea: true that support is an issue, but this is a high
demand issue

netmanage: how does the duplicate notification work given
provider only knows about one socket?

davea:  ws2 dll would be responsible for doing the multiple
notifications and doing it multiple times if necessary

netmanage: WSAAsyncSelect has its own window handle

davea: spi doesn't necessarily take window handle.
callbacks into ws2 dll handle all notifications.

netmanage: so provider handles callbacks and ws2 dll does
notifications?

henry: what do you all think about independent
notifications?

?: concerns about complexities with independent
notifications

digital: select is done in providers

wrq: this imposes lots of complexity given few apps care
about it

novell: asyncselect is not passed down?

davea: that is true in 16bit spi--the "select" for 16bit spi
is different

henry: counterexample: fd_close is a different issue

davea: yes people want that

henry: but there is an ipc that people need to use, so force
those applications that care about it to handle
crossnotification

ibm: don't overengineer, force complex app to deal with it

davea: depends on how people want to use it.

henry: finding out about close is not difficult if you are
reading/writing.

davea: only reason for ipc is if that is the common
mechanism

distinct: what about blocking sockets?

davea: a socket is either blocking or not

distinct: if one thread does send, another does recv, does
second io fail?

davea: yes, 2nd one fails

dvaea: need to keep requirement, let's discuss later

sunsoft: WSAEINPROGRESS on nonblocking sockets?

davea: how does it work in nt/win95?

davidtr: description of multiple send/recv in nt/win95

wrq: but it is an issue in win16

henry: you need more reentrancy in order to successfully
implement it in win16

netmanage: can sender be blocking and recvr nonblocking?

davea: no

distinct: that is a good argument for having one
notification

sunsoft: agrees

henry: agrees

?: if we dupe it and pass it off, do we lose access?

davea: two models are independent notification (each process
independently registers interest in multiple events).  other
model is that for a particular network event only one
process can register interest.

?: ??

davea: model is like for WSAAsyncSelect; latest requestor of
a particular network event gets it

?: other things are getting duplication, you are about to
transfer, and you die?

davea: handles are equivalent, so os should deallocate
resources, sockets are opened

?: when does that socket handle go away?

davea: when last reference goes away

att: but if the last one has registered notification, what
happens?

netmanage: a different api for giving away a socket?

davea: problem is that you cannot simple hand a socket to a
different process.

netmanage: wants it to be simplier.  all apps she has are
wanting a handoff, not shared sockets.

davea: multithreaded server it is not an issue

distinct: wsaasyncselect spec needs to change; a 2nd call in
current spec wipes out last asyncselect setting.

davea: associated notification mechanism is with HANDLE not
SOCKET

jsb: one socket ID for the svc provider.  multiple dupes ref
several handles.  davea proposal is that asyncselect is
specific to each handle, not to each socket.

davea: example of how this works.

distinct: what about socket options?

davea: socket options are part of intrinsic socket?

distinct: what if you set a socket to blocking/nonblocking?

henry: apps need to coordinate.  the burden should be there.

att: which if any behavior is documented?

davea: believes that it says notification is independent

henry: any good examples of why you need independent
notifications other than fd_close?

davea: fd_qos

alden: one oob thread

henry: shouldn't be an issue

davidtr: other notification mechanism: wsaeventselect

netmanage: do we have an api to read events that have
occurred on a socket?

davea: yes, wsaenumnetworkevents

netmanage: wsaasyncselect query mechanism?  tell what it is
currently doing?

davea: no plan to implement that because no perceived need

keith: if you set it, you should know what it is set to

?: shared sockets you can get an error code if you register
an event that another process has?

davea: that is one possibility

netmanage: ?

davea: processes need to cooperate--that is inherent.  let's
continue.

***

digital: does 1st accept() complete?  (return)

davea: yes

distinct: isn't tcpip supposed to send an ack right away?

ftp: can hold off on sending your own syn

novell: why not a wsareject?

davea: couple of ways to implement it.  when you call
wasaccept it tells you about someone trying to connect,
another call to get addr, another to accept; this si 3 apis
and is complicated

digital: decnet has sockopts for this

netmanage:  what happens if you have multiple
sockets/connections?

davea: this does not change queuing model.  there is still
the same queue.  when you get an incoming conn request and
defer, you have not popped the queue until you accept or
reject it.  you cannot process other incoming connects until
you process the 1st one.

distinct: fd_accept is reenabled on???

davea: reenabled after you either accept or reject, not
defer

sunsoft: is there an exact desc of what is passed to
condition func based on different protocols?  wants ip addr

davea: yes you get sockaddr of caller

***

att: ignore connect data as opposed to failing if not
supported?

davea: fails with an error.  also in protocol_info struct.

henry: what about protos with limited sizes of connect data?

davea: should probably be in protocol_info struct

att: a single field of maxlen would solve it

davea:  good idea

***

sunsoft: oob flag must be set if data read is oob?

davea: not sure.  oob is bad.

digital: decnet apps use oob.  historical references?
datagrams?

davidtr: from xti, designed for reliable protocols

digital: what is the precenence?

henry: existing interfaces return error and discard extra
data.  reliable protocols need the flag.

novell: there was talk of returning -1*bytes read if partial
message

davidtr: description of nt WSARecvEx

att: so this flag is just like xti recv function?

davidtr: yes

***

henry: is there a way to resolve open issues?

davea: easier to resolve issues in person, but we just
dumped lots of info

ftp: this doesn't address dns, etc

davea: this is just generic and operating framework groups

henry: just presenting those groups, other subgroups do the
rest, including integration of their proposals.

davea: so we need to get this on ftp srvs asap so other
groups can start making proposals

ftp: do we consider config params involved in spi?

davea: what kind of config params?

ftp: dns server, send size, dns timeout.  will we define
this mechanism?

davea: nameres group

ftp: what is the mechanism itself?

jsb: two components: data transfer, name resolution, as
separate proposals.  do other group proposals fit well with
what dave and keith have done?

ftp: I don't understand who does configuration

others: what do you mean?

ftp: dns servers, domain name

henry: programmatically configurable?

ftp: does each dev create their own params?

davea: ws1.1 did no config params

jsb: people have wanted to programatically set these.  ws2
does not include these as requirements.

henry: these issues are specific to various func groups.  no
generic need for a suite of apis to solve this.

novell: a svc provider can do this on their own.

ftp: dns svc should be in a well known place so that when
you switch providers the new provider can leverage the old
info

henry:  no need for a common place

wrq: management nightmare.  registry has a solution for
this.

novell: rules for querying config info?

henry: hasn't seen provider update be an issue

ftp: if you want to move a hosts file between systems,
you're hosed--no consistency.  where to put config params?

davidtr: not in scope of winsock group

davea: have func groups make suggestions

wrq: load order of providers, how to define this?  what if I
have multiple versions of my provider?

davea: when you do install, you create protocol_info that
points to specific dll.

ftp: this is the start of config info.

keith: the install apis hide that

henry: we are defining api + architecture, not config

sunsoft: do you need to get dns server besides from where
your system has config'ed it?  programmatically?

ftp: ws2 provided by intel + ms doesn't take any config
params?

henry: install apis do take protocol_info struct.

jsb: one issue is how much we can hope to achieve.  it would
be nice to have it consistent, conventions might be nice.
to keith: does anything return seciton in ini file where svc
providers put config info?

keith: no, that info is hidden, opaque.  convention about
where these things live.

ftp: so ws2 dll requires no config info?

keith: no, install apis

ftp: ws2 dll comes from you, svc provider comes from me,
does ws2 dll need any config info?

davea: yes, provider must call install apis.  when someone
wants you, I call you.

ftp:  does this mean that future params to ws2 dll are
passed to install apis?

davea: no

henry: if ws2 dll had "max protocols to support" how to
support?

davea: those params do not exist and are not being
considered.  never say never, but they are not foreseen.

wrq: will install function deal with contention?  2 dlls
with same name?

keith: you pass in a unique name to install api

davea: when you get a triple, we find first provider that
meets that

wrq: what is app does enumprotocols?

davea: he gets them all

wrq: and if they install two copies of the same stack?

davidtr: install api takes unique name, fails if exists

davea: also good to call enumprotocols to be safe

digital: timeframes?  set deadlines on comments?  voting?

henry: depends on what people can digest in a period of time

davea: late jan meeting:  good to have a position on what to
say to rev board.  by xmas, spec on ftp servers for other
groups.  not final, but reflect general approach.  give
feedback if approach is totally wrong so we can make
changes.  want violent oppisition about missing things now.
xmas to end jan knocking off details.  what do people feel
about voting?

distinct: how to resolve open issues?

davea: some today.  but there may be reservations about
solving all issues too soon.

digital: need timeframe to help people know deadline

att:  good to start discussing issues to get a feel for what
people feel

davea: look at pad, try to come up with reasonable dates.
may be other open issues that pop up later.

netmanage: how does ws2 dll discover what events have
occurred below it?

davea: 16bit dll provider makes upcall, ws2 dll does
notification.  32bit world stack does it itself.

***

break, martin talks

***

wrq: in original meeting, did we discuss management apis?

jsb: winsock is not snmp

netmanage: room for one more document.  ws2 takes care of
blocking, asyncselect, many things in ws2 dll.  good if we
have another doc which defines what the provider supports.

keith: spi spec documents that.

netmanage: gethostbyname()

keith: nameres group issue

davea: in conversations with nameres group, the getXbyY
issues are handled by nameres

davea: for moving a stack to ws2, it should be easy

wrq: name resolutions unique to xport?  e.g. hp probe which
is name-->addr addr-->mac resolution issue.

digital: how does nameres group meet?

davea: depends on margaret, mark of nameres group

distinct: who consolidates documents?

martin: depends on what is most pragmatic?

davea: two or three documents--nameres, api, spi

novell: are nameres pieces independept of provider?

davidtr: yes

ftp: namespace provider independent of transport provider?

davea: yes

ftp: ws2 coming from ms/intel.

davea: multiple documents

wrq: means for resolving conflicts

davea: follow same model, can pick a particular provider if
you want

sunsoft: ws2 strawman spec only delineates new apis, ws1.1
is incorporated by default (yes).  ws1.1 migration: users
and developers of ws1.1 apps.  question is can we look to a
way that ws1.1 apps run unchanged on new architecture?  they
use similiar triple, and this is a very important thing in
order to preserve momentum.  vendors will be torn between
support for ws2 and ws1.1?

davea: problems include single app which uses a middlewear
dll.  dll uses 1.1, app uses 2.0.

distinct:  at last meeting, concensus was that a new dll
name is required.

henry: it should work, however, if there are no semantic
differences between 1.1 and 2.0.

many: issue is whether semantic issues will exist?

henry: no strong opinion!  two solutions: one is
winsock.dll, other is a new dll with a new name.

sunsoft: app vendor does not want to write multiple versions

henry: some apps will require new features

sunsoft: propagation issue; ws2 will take a while to get
there

keith:  need to mandate that there will be a winsock.dll
which supports old applications

ftp: what would be wrong with providing a new ws2 dll called
winsock.dll, include ws1.1 emulation

distinct: registration will not work

henry: we could do that if there are no semantic changes

distinct: not practical to make runtime decision on whether
to use 1.1 or 2.0

davea: mark says app vendor doesn't want to support both ws2
and 1.1.  if app does not require ws2 capabilities, then the
app can still be written to 1.1 and ask for 2.0 and continue
if it does not get it.

mark: issue is that a winsock.dll must exist

davea: app can protect itself

mark: if ws2 dll can handle someone asking for 1.1 then we
are ok.  this is an important goal.  if we do not do that,
someone will write a broken dll.

distinct: problem in current spec says that subsequent
version requests different version number.

mark: will break 90% of things if we lack basic agreement

firefox: mapping layer into ws2 dll called winsock.dll would
solve the problem.

mark: this would not have the foresight that we have here

davidtr: requirement for "winsock.dll", there may be a
separate winsock dll

distinct: might not work

davea: rpc dlls etc. are important

henry: only the 1st request actually does something

davea: scary because of ordering concerns

navy: what is ws2 dll is the shim?

keith: then no need for a separate dll

navy: old app does not know about new dll, just works

ftp: wants to keep only one dll name because that is the
most sensible mechanism; doesn't require a loadlibrary.
don't complicate dev process.

keith:  need to mandate winsock.dll.  shim or dll is at
issue.

ftp: still doesn't want to do the load.

navy: shimming the other way solves this problem.

henry: wsastartup solves this problem, handles multiple
versions.

dirk: as long as ws2 is a pure superset

ftp: clarificatrions are small, not big impact

henry: clarifications to fd_close are fine

davea: is it ok to have "winsock.dll" that supports both ws2
and ws1.1?

many: that should work

henry: we will have to be careful about this

wrq: version negotiation must be task specific, need to
specify this

davea: if 2.0 dll just handles 2.0 or 1.1, is that ok?

mark: clarifies

henry: fine as long as no smeantic changes

davea: app shouldn't care

netmanage: in ws2 scheme, is there a default provider?

davea: af_inet, stream/dgram, first one defined is the
default

netmanage: user should be able to choose

davea: rearrangement of order is an interesting question

davea: close to resolve an issue:

mark: there will be one winsock.dll that handles 2.0 and 1.1
semantics

novell: how do you distinguish between 16bit and 32bit with
ws1.1 and ws2.0

many: not an issue

distinct: issue with blocking between 1.1 and 2.0?

keith: should be no difference in blocking at the api level

davea: 16bit is pseudoblocking, 32bit is real blocking

henry: in 32bit there is true blocking

mark: shouldn't be semantic differences

distinct: revisit wsaasyncselect has semantic changes with
shared sockets

davea: that could happen.

many: provide a new api if that happens.

davea: depends on the model we choose and may introduce a
new semantic for wsaasyncselec.  for 1.1 you cannot change
the behavior.

davea: no semantic differenecs that effect 1.1 applications.

netmanage: if socket is shared, blocking, is there a
different blocking hook? on a per process basis?

mark: blocking hook is per thread.

davea: scatter/gather description.  anyone feel strongly?

wrq: yes!

mark: why?

wrq: performance, netbios consistency

ftp: any dll that implements rpc ftp or attaches some header
will need this

novell: novell always supplies this, so it is goodness

ftp: only prob for svc provider is whether transport
supports it.  but you can always do a buffer allocation and
buffer copy.  if provider does not do it, ws2 dll should do
it.

many:  issues with who owns the buffer

?: allow for it on a provider optional basis

many: groan

henry: vendors with a problem implementing it?

nobody says yes

henry: being nice, maybe we should do it.


davea: general sense is that it should be in there.  move on
to WSASocket taking a protocol_info struct.

many: sounds like a good idea

wrq: who provides protocol_info struct?

davea: provider supplies on installation

wrq: when do you get it?

davea: enumprotocols

wrq: app buffer space gets it

now on to the independent notification

navy: easy to do independent notification

henry: there is a way to do independent notification via
eventselect.  maybe we just say that async select does not
do this.

davea: reiteration: for each fd_ event, a windows messages
goes to one and only one window.  if process a registers for
fd_read and b registers for fd_read, does b get the
semantics or does b fail?

wrq: there is no way to determine whether an asyncselect is
outstanding.

henry: we are assuming cooperating applications, after all.

wrq: envision a server that kicks off other threads to do
things

henry: threads != processes, need to agree on high level
concepts before addressing specific issues

davea: there is a motion that for shared sockets a
particular network event is independent

davidtr: 1.1 defines that the latest wsaasyncselect
overrides previous calls

davea: process a registers for whatever it wants, process b
registers for other things, but no overlap.

navy: how is this different from independent notifications?

henry: easier to implement, cleaner because morass of
rearming is avoided, and another mechanism is available to
app writers have eventselect to solve the same problem

davea: eventselect does this, as long as your app does not
want to block

davidtr: overlapped io can also solve this

davea: yes

netmanage: how does this work?

davidtr: description of overlapped io, events

davea: but we don't want to share events across tasks

discussion on how events work in different environments

navy: not many people will want to do this, but it keeps it
symmetric for multiple applications.  any read on the socket

davidtr: these must be cooperating applications

henry: cost of implementing this outweighs value to some
limited set of applications

navy: believes that independent notification is easier to
implement

mark: we should be grounded in practicality, do not include
something unless it is really useful

davidtr: how many implementors feel that independent
notification is easier?

intel says it is easier for them?

wrq: if message handler fails, what do you do?

dirk: slap info on queue, wait and try later

wrq: repost on a per task basis

dirk: yes

mark: is this really required?

davea: fd_close, fd_qos could be of interest to multiple
tasks

henry: speculates that you will have a master process that
can receive notifications

davea: apps can always do it either way, but what is
easiest/most common usage model?

mark: agree on fd_close, but not on fd_read

davea: consistency?

mark: fd_read must be totally out

wrq: how would you implement app so that it does not get
reads in both applications

davea: making it possible for read and write to multiple
processes does not make any sense.  do it one way or the
other.

navy:  can peek at data, multiple tasks may care about
fd_read

digital: idea that multiple selects that come down is not a
novell concept

henry: system hides multiple handles

davidtr: description on how it works on win32

walldata: will not use this mechanism anyway, will use ipc
mechanism to communicate.  this feature is too contentious
to be consistent.

many:  believe that shared sockets will still be used.

netmanage: implemented in ws2 dll

many: incorrect

davea: we will not bottom out on this, so we should
carefully word this and take it to the mailing lists

ibm: thanks intel and davea

mark: describes different possible data structures for
providers for async select: for each event, one hwnd/socket
per event, multiple hwnds/sockets per event; one hwnd/socket
for all events.